@drake999
10-4. Just just curious about others thoughts on the subject. The stock power port is protected, the gpio are not. Just an observation more or less

Does anyone have any further suggestions before I give up on this?

@mitu True. I forgot they added the favorites/recents. I was referring to just the metadata. Good catch

@cgeyik I think learning to solder would be the easiest option. As the case comes, the power/reset are hard wired into the power in and all current flows through both buttons. I just cut the traces to the switches, which isolated them from the power circuit and allows them to be used for other purposes, and soldered power in directly to the pins that go to the pi. So eventually you’ll have to solder something to the power in. I did a whole rundown of my build in a couple threads.

How to perform a software shutdown with the Mausberry and the diode/transistor hack?

NOTE: This does only work on momentary switches!

1. Prerequisites
You need to solder a diode (1N400x type 1N4001 or 1N4002) or a transistor (NPN-Type, 2N3904, BC547 or BC337) to the Mausberry on/off switch.
For the diode: Connect it between a GPIO and the mausberry button ground.
The transistors needs to soldered between ground and positive to the switch and the base line is connected to the GPIO (maybe you need a resistor to control current flow)

Therefore I strongly recommand the DIODE hack!

Don't be afraid the Raspberry is in both ways protected against current backdraws! Use the diode or the right direction as shown in the box above....

GPIO MAUSBERRY from Pie DIODE switch ground O---------------->|----------------O 1N4002

More to read here

2. Software part

Create gpio-shutoff with sudo nano /lib/systemd/system-shutdown/gpio-shutoff Enter code from box below Make the script executable with sudo chmod +x /lib/systemd/system-shutdown/gpio-shutoff

GPIO16 (or PIN 36 ) is just an example here and is my real setup

#!/bin/sh # Perform Software Shutdown with Mausberry switch # cyperghost for retropie.org.uk # This is the GPIO pinconnected to the diode or transistor GPIOpinDIODE=16 if [ "$1" = "poweroff" ]; then echo $GPIOpinDIODE > /sys/class/gpio/export echo out > /sys/class/gpio/gpio$GPIOpinDIODE/direction echo 1 > /sys/class/gpio/gpio$GPIOpinDIODE/value sleep 0.5 echo 0 > /sys/class/gpio/gpio$GPIOpinDIODE/value sleep 0.5 fi

3. Software script with proper Reset and Shutdown
This is the full working bash script
Installation:

add it to /etc/rc.local/ add it to /opt/retropie/configs/all/autostart.sh` whatever case you select make the script executable with chmod +x scriptname.shand add sudo yourscript.sh & to choosen autostart

This script adds:

Working Reset button
1.1 if an emulator is running it will end this
1.2 if ES is running (without emulator) a restart of ES will be made Working shutdown button #!/bin/bash # Mausberry shutdown script v3 # # extended by cyperghost for # Yet annother NESPi case # Tested version 15/01/18 es_action() { case $1 in check) [[ -f "/dev/shm/runcommand.info" ]] && \ emu="$(sed '4!d; s/\([\\"]\|[[:alnum:]_]\+=[^ ]* \)//g; s/[][(){}^$*.|+? ]/\\&/g' /dev/shm/runcommand.info)" && \ [[ -n "$emu" ]] && emupid="$(pgrep -f "$emu")" && \ rcpid="$(pgrep -f -o runcommand.sh)" espid="$(pgrep -f "/opt/retropie/supplementary/.*/emulationstation([^.]|$)")" ;;#" restart_es) touch /tmp/es-restart && chown pi:pi /tmp/es-restart [[ -n $emupid ]] && kill $emupid && es_wait $emupid && es_wait $rcpid [[ -z $emupid ]] && kill $espid && sleep 5 ;; shutdown_es) touch /tmp/es-shutdown && chown pi:pi /tmp/es-shutdown ;; esac } es_wait() #Wait function for finishing running emulators { while [ -e /proc/$1 ] do sleep 0.15 done } #this is the GPIO pin connected to the duoLed RED GPIOpinLED=21 #this is the GPIO pin connected to NESPi RESET siwtch GPIOpinRESET=20 #this is the GPIO pin connected to the lead on switch labeled OUT GPIOpin1=19 #this is the GPIO pin connected to the lead on switch labeled IN GPIOpin2=26 #SWITCH LED ON echo "$GPIOpinLED" > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio$GPIOpinLED/direction echo "1" > /sys/class/gpio/gpio$GPIOpinLED/value #Initiate RESET echo "$GPIOpinRESET" > /sys/class/gpio/export echo "in" > /sys/class/gpio/gpio$GPIOpinRESET/direction #Initiate MAUSBERRY SWITCH echo "$GPIOpin1" > /sys/class/gpio/export echo "in" > /sys/class/gpio/gpio$GPIOpin1/direction echo "$GPIOpin2" > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio$GPIOpin2/direction echo "1" > /sys/class/gpio/gpio$GPIOpin2/value power=$(cat /sys/class/gpio/gpio$GPIOpin1/value) reset=$(cat /sys/class/gpio/gpio$GPIOpinRESET/value) until [ $power = 1 ]; do power=$(cat /sys/class/gpio/gpio$GPIOpin1/value) reset=$(cat /sys/class/gpio/gpio$GPIOpinRESET/value) [ $reset = 0 ] && es_action check && es_action restart_es sleep 1 done # Power button pressed? if [ $power = 1 ]; then es_action check [[ -n $emupid ]] && kill $emupid && es_wait $emupid && es_wait $rcpid es_action shutdown_es kill $espid && es_wait $espid exit #Give back maincontrol to emulationstation.sh fi poweroff

4. Why are you doing this?
The Mausberry gots a little design issue. If you performing a software shutdown (maybe via ES > Shutdown system or via SSH sudo poweroff) the PI will shut down but the Mausberry will stay active (LED is on). Furthermore it won't respond to a power button press anymore - it's stuck! So you have to switch it off completly by removing your wall plug or by resetting the Mausberry.

The diode or transistor just simulates a button press and the Mausberry will properly shutdown ;)

5. Closing words
It would be better to use @meleu's nice shutdown service in addition with the gpio-shutdown in section 1 and 2. The great benefit of this is you don't need to modify any scripts that are part of ES or to edit any script in meleus package.

The button-script is intended to give an example how to perform faster shutdowns (by bypassing sleep timers) and to show the difference between a while-loop with enclousured if-clause in it and a better choosen until-loop with external if-clause ;) - I recommand a script that is python powered ;)

Link to meleus shutdown service is here

@atexplosion

I'm an electrical engineer, and I recently spent a day debugging all the boards and wires in my Nespi case because of the undervoltage alarm. I also tried multiple cables, power supplies, and other brands of cases, with and without fans. My conclusion ended up being that all of my USB cables were inferior, and I will explain why.

For starters, Ohm's Law states that DC electric potential is equal to the product of current and resistance in a circuit (V = I*R).

All conductors (wires) have an associated resistance (R, measured in ohms [Ω]). At low current (I, measured in amperes [A]), the effect of wire resistance is negligible. At higher current values, that effect becomes significant, causing a "voltage drop" (V, measured in volts [V]). A Raspberry Pi running Retropie has a pretty high current load compared to generic USB devices (like an optical mouse, or a game controller).

For a given cross-sectional area, a copper wire has an intrinsic resistivity (that is, resistance per unit length, or Ω/m [ohms per meter]). Depending on the given USB cable, the power conductors typically range from 28 AWG to 24 AWG (0.08 to 0.25 square millimeters cross-sectional area), with the largest available (that I know of) being 19-AWG (0.653 square millimeters).

The resistances of these three wire gauges at 10 ft are the following:
28 AWG @ 10 ft -- 0.649 Ω
24 AWG @ 10 ft -- 0.257 Ω
19 AWG @ 10 ft -- 0.081 Ω

Assuming an average current of 0.800 A (800 mA) for a medium-usage Raspberry Pi 3B+, using Ohm's Law, that would yield the following voltage drops:

28 AWG @ 0.8 A, 10 ft -- 0.52 V
24 AWG @ 0.8 A, 10 ft -- 0.21 V
19 AWG @ 0.8 A, 10 ft -- 0.07 V

For a 5-volt power supply, that would mean the voltage at your Raspberry Pi's micro USB connector would be the following:

28 AWG @ 0.8 A, 10 ft -- 4.48 V
24 AWG @ 0.8 A, 10 ft -- 4.79 V
19 AWG @ 0.8 A, 10 ft -- 4.93 V

The shorter your cable, the effects become lessened:

28 AWG @ 0.8 A, 5 ft -- 4.74 V
24 AWG @ 0.8 A, 5 ft -- 4.90 V
19 AWG @ 0.8 A, 5 ft -- 4.97 V

28 AWG @ 0.8 A, 2.5 ft -- 4.87 V
24 AWG @ 0.8 A, 2.5 ft -- 4.95 V
19 AWG @ 0.8 A, 2.5 ft -- 4.98 V

Increasing the size of your power supply (higher current output) really won't get around these effects. Maybe going to a higher voltage would compensate for the drop, but your current changes constantly, causing the voltage drop to change constantly. You'd be risking damaging your Pi. The best solution is using the shortest standard cable available, or buying a cable with larger conductors if you need a longer length (the company Volutz offers the largest that I could find).

The PCB boards in the Nespi case do slightly exacerbate the issue, but the biggest culprit is the main power cable. Once it's of sufficient length and/or gauge, the effects of the Nespi boards are negligible. I even had undervoltage faults using no case at all when I had a long power cable with thin wires.

So, use a really short cable if you can, and you should have no issues, even using a Samsung phone charger.

Cheers,
Than MacKenzie

How about you use the reset on the Raspberry Pi itself?

@cyperghost thnx, i Will try iT.